Complex, processing time intensive computations in modern computer systems are typically performed as a sequence of individual computation steps. In this context, Service-Oriented Architectures (SOA) are increasingly used for controlling multiple services each executing a computation step and running on distributed computers in order to work together to execute the overall computation process. During the execution of the computation process, a huge number of resources may be consumed and produced as inputs, outputs and intermediate results. Such resources may be documents that comprise e.g. engineering data of a new automobile under development or other highly confidential data. Avoiding access to the confidential resources by unauthorized users is crucial in order to ensure the security of the overall computation process. Users may in this context be human users or other computer systems or computation steps.
From the prior art, techniques are known for ensuring instance-based document security. To this end, a collection of so-called principals (e.g. users, roles, groups, etc.) may be defined in such systems. Each document that is subject to security, i.e. that comprises security-relevant information, has a list of security settings attached that define which principal has which access right/access privilege (e.g. read, update, delete, etc.) upon the respective document. Typically, security settings are not only attached document-wise but defined individually for different document versions. Security settings, also called policies, may e.g. be defined by access control lists (ACL). However, in view of the huge number of resources involved in complex computations, which typically consume and produce thousands of resources in different versions, defining adequate security settings for each individual resource or resource version is highly difficult or even impossible. This problem is commonly solved in the prior art by granting a user far too many access rights or, even worse, an overall access right, which poses a severe security risk, since the confidential information could be freely accessed. Therefore, access rights must be applied as restrictive as possible.
Furthermore, especially security-related processes have to be maintained, i.e. inspected on a regular basis and possibly modified in order to ensure that the security-related process works as expected. The problem of granting adequate access rights is intensified in this context. Such maintenance or inspection is typically done by special maintenance/inspection users that on the one hand, need a certain level of access to the process, i.e. to the resources involved in the computation in order to perform the maintenance, but on the other hand, are not supposed to access certain highly confidential resources under any circumstances. The special maintenance users therefore need the exact access rights for the exact resources they are allowed to access. However, defining such exact access rights once the maintenance is due is just as difficult as initially defining access rights for the computation personnel. Additionally, when the process is modified, all access rights have to be modified accordingly in order keep the security definitions up to date and to not accidentally create security holes. Furthermore, even the discovery of which resources are actually involved in the respective process, i.e. which are the resources the maintenance/inspection users are supposed to see, is highly difficult and ineffective given the potential huge amount of resources and processes.
In the field of computer networks, the U.S. Pat. No. 7,451,071 discloses a data model for automated server configuration that allows for modeling of information relating to a computer network to be stored in a database while minimizing the effort associated with the addition of new devices to the network. The data model deals, among others, with configuration information such as ACLs. However, the document discloses a proprietary data model that is specifically designed for server configurations, which is not compatible for being employed in the field of complex computation processes, let alone SOA environments.
Furthermore, the European patent application EP 1850288 discloses an insurance policy revisioning method and apparatus. An insurance policy is stored as a plurality of discrete temporally-sequential policy data revisions. A legally binding revision for a first given date is then determined by identifying all policy data revisions effective on the first given date and choosing a most temporally recent policy data revision temporally prior to a second given date. However, the document does not relate to the granting of exact access rights in such a policy revision.
In view of the above, it is therefore the technical problem underlying the present to provide a more secure approach for granting a user secure access to the resources accessed by a process that involves only the exact access privileges required, thereby increasing the security and at least partly overcoming the above explained disadvantages of the prior art.
This problem is according to one aspect of the technology solved by a method for granting a user secure access to one or more resources accessed by a process, the process being defined in a SOA registry and comprising one or more process-steps, each process-step accessing one or more resources stored in a SOA repository. In the embodiment of claim 1, the method comprises the following steps:                a. during an execution of the process, for each resource accessed by at least one of the process-steps, creating an entry in the SOA registry determining the accessed resource;        b. creating a process-instance-role in the SOA registry;        c. for each resource accessed by at least one of the process-steps, creating an access privilege in the SOA repository that grants access to the respective resource for the process-instance-role; and        d. assigning the process-instance-role to the user.        
Accordingly, during an execution of a process, the resources accessed by the individual process-steps are recorded or logged in corresponding entries in the SOA registry, e.g. in the form of pointers or references onto the corresponding resources, or any other suitable form. Such resources may be documents comprising e.g. engineering data of a new automobile under development or other highly confidential data that may be accessed—i.e. created, updated, deleted etc.—during the execution of the process and its process-steps, respectively. This logging of the accessed resources has the advantage that when the process is to be inspected/revised later, it can be easily determined which resources were involved in an execution of the process by simply inspecting the corresponding entries in the SOA registry that were created or logged during the execution.
Furthermore, a process-instance-role is created in the SOA registry. Moreover, a corresponding access privilege is created in the SOA registry for each resource accessed by at least one of the process-steps. The access privileges grant access to the respective resources for the process-instance-role, i.e. they control the type of access in which the process-instance-role or a user having this role, respectively, may access the respective resources.
Finally, the newly created process-instance-role is assigned to the user. Due to his assigned role (the process-instance-role), the user is thus granted the exact access privileges he needs for the secure access to the process, i.e. to the exact resources involved by the corresponding process execution. This greatly improves the overall security, since the user is prevented from accessing other resources which do not relate to the corresponding process execution, e.g. confidential information which should be kept secret at all costs. The present technology is furthermore especially advantageous over instance-based document security known from the prior art in that access privileges are not defined document-wise, but rather process-oriented. This greatly reduces the effort when creating the access privileges and serves for a concise and adequate definition of access privileges required for a controlled and secure access to the processes' resources.
According to another aspect of the present invention technology, the above-described method steps b. and c. are also performed during the execution of the process, i.e. the creation of the process-instance-role is performed at some point in time during the process execution and preferably at the beginning of the execution. Furthermore, whenever one of the process-steps accesses a resource, a corresponding access privilege is created in the SOA registry. This is particularly advantageous, since the creation of all roles and access privileges in the SOA registry is performed automatically during, i.e. in parallel to the process execution. Thus, when a later inspection of a process is due, all required roles and access privileges are already available in the SOA registry in an up-to-date, correct and secure manner, so that the user who is responsible for the maintenance or inspection can undertake his task immediately. Lastly, also the step of assigning the process-instance-role to the user may be performed during the execution of the process, or alternatively at a later point in time.
It should be furthermore noted that the above-described method may be performed once for every execution of a process, i.e. one set of the above-described registry entries, roles, access privileges, etc. is created per process execution. The user may be assigned all of the resulting process-instance-roles or only a subset of the process-instance-roles, depending on which process executions the user is supposed to access. Especially when the process is later modified by a special maintenance user or inspected by a special revisor user, the present technology elegantly and reliably solves the problem of granting such users the exact and minimal access rights they need.
According to another aspect of the present technology, the method may comprise the further steps of creating a process-instance in the SOA registry representing the execution of the respective process, for each process-step executed by the process, creating a process-step-instance in the SOA registry representing the respective process-step and creating a relationship to the respective process-instance, wherein the entries created in step a. are added to the respective process-step-instance. Preferably, these steps are also performed during the execution of the process. Accordingly, the sequence of process-steps carried out during a process execution are logged in the SOA registry by creating corresponding registry entries, such as a process-instance entry corresponding to the process execution and process-step-instance entries corresponding to the process-steps performed during the process execution. In this case, the entries which determine the resources accessed by the process-steps may be added to the corresponding process-step-instances. This has the advantage that when a certain process is to be inspected, the SOA registry already comprises the exact information of all executions of the process, the exact steps performed by the executions and the resources accessed by these process-steps can be easily determined by inspecting the respective process-instance-step registry entries.
According to a further aspect, the entries created in step a. which determine the resources accessed by the process-steps, may also determine a type of access to the respective resource, wherein the type of access is one of the group comprising: create, update and/or delete or any kind of other type of access the process-steps performed on the resources during process execution.
Furthermore, the method may further comprise the steps of creating a process-role in the SOA registry, adding the process-instance-roles to the process-role and assigning the process-role to the user. Accordingly, not only each individual process execution is accompanied by a corresponding process-instance-role, but the process itself is further accompanied by a process-role, which is preferably the union of all process-instance-roles of the processes' executions. Hence, if the user is supposed to be authorized to revise all possible executions of the process, he simply needs to be assigned the process-role. It should be appreciated that the process-role may be automatically created when the process is initially defined, when the process is executed for the first time or at any other suitable point in time. Furthermore, the addition of the process-instance-roles to the process-role may be performed each time a new process-instance-role is created, i.e. during each execution of the process. Similar to the assignment of the process-instance-roles to the user already described above, also the process-role may be assigned to the user manually or automatically during process-execution, process definition, or alternatively at a later point in time.
In yet another aspect of the present technology, each of the one or more access privileges may be one of the group comprising: a read privilege, an update privilege and/or a delete privilege. Preferably, however, the access privileges associated to the process-instance-roles are read privileges. Since the user responsible for maintaining or inspecting the process only typically needs to view, i.e. read, the resources associated with the process, this ensures that a minimal set of access privileges are granted to the user. Additionally or alternatively, an access privilege may be another privilege such as write, update, create, delete or any other privilege needed by the user in order to undertake his tasks.
Furthermore, the one or more resources may comprise a plurality of resource-versions and during the execution of the process, each process-step may access a specific resource-version, wherein the entries created in step a. determine the respective resource-version and wherein the access privileges created in step c. grant access to the respective resource-version. Accordingly, the present method may be easily extended for supporting resources which are stored in the SOA repository in any number of different resource-versions, so that the user only gets access to the specific resource-versions he is allowed to access.
Furthermore, the created access privileges may be later edited either manually, e.g. by specially authorized personnel, or automatically, e.g. by applying appropriate rules. Editing an access privilege may comprise the actions of adding or removing allowed types of access, completely deleting an access privilege or any kind of other action suitable for fine-tuning the access privileges as needed.
Preferably, the access privileges are WebDAV access control lists (ACLs), which are explained in more detail in the detailed description below. In this case, the creating of appropriate access privileges in step c. may be accomplished by adding a corresponding entry to an ACL associated with the respective resource. Similar to the explanations above, the ACL may only allow read access to the respective resource for the process-instance-role in order to minimize the risk of security breaches, or alternatively any other kind of suitable type of access.
The present technology further relates to a SOA registry and to a SOA repository for granting a user secure access to one or more resources accessed by a process, wherein the SOA registry and the SOA repository are each adapted for use in any of the above presented methods. Furthermore, the technology concerns a SOA environment comprising both a SOA registry and a SOA repository of the above described type. Lastly, the present technology is also directed to a computer program comprising instructions for implementing any of the above methods.